One other fun part of gene editing in vivo is that we don't actually use GACU (T in DNA). It turns out that if you use Pseudouridine (Ψ) instead of uridine (U) then the body's immune system doesn't nearly alarm as much, as it doesn't really see that mRNA as quite so dangerous. But, the RNA -> Protein equipment will just make protiens it without any problems.
Which, yeah, that's a miraculous discovery. And it was well worth the 2023 Nobel in Medicine.
Like, the whole system for gene editing in vivo that we've developed is just crazy little discovery after crazy little discovery. It's all sooooo freakin' cool.
https://en.wikipedia.org/wiki/Pseudouridine
> To accomplish that feat, the treatment is wrapped in fatty lipid molecules to protect it from degradation in the blood on its way to the liver, where the edit will be made. Inside the lipids are instructions that command the cells to produce an enzyme that edits the gene. They also carry a molecular GPS — CRISPR — which was altered to crawl along a person’s DNA until it finds the exact DNA letter that needs to be changed.
That is one of the most incredible things I have ever read.
This is not "malicious compliance", this is more like "pedantic enforcement".
"Malicious compliance" would be if the same team booked a 50min meeting then a 10min meeting in the same room.
It's nice to see a paper that confirms what anyone who has practiced using LLM tools already knows very well, heuristically. Keeping your context clean matters, "conversations" are only a construct of product interfaces, they hurt the quality of responses from the LLM itself, and once your context is "poisoned" it will not recover, you need to start fresh with a new chat.
We feel your pain at Nextcloud. Our team at Everfind (unified search across Drive, OneDrive, Dropbox, etc.) has spent the past year fighting for the *drive.readonly* scope simply so we can download files, run OCR, and index their full-text for users. Google keeps telling us to make do with *drive.file* + *drive.metadata.readonly*, which breaks continuous discovery and cripples search results for any new or updated document.
Bottom line: Googles "least-privilege" rhetoric sounds noble, but in practice it gives Big Tech first-party apps privileged access while forcing independent vendors to ship half-working products - or get kicked out of the Play Store. The result is users lose features and choices, and small devs burn countless hours arguing with a copy-paste policy bot.
Airbnb made the same mistake Google did: They screwed up their core service. I used to be a steady ABB customer but now hotels are almost always cheaper, offer better service, and are more predictable.
Not to mention that hotel websites are typically easier to navigate and contain a lot less React-sludge that makes every click take forever to respond.
“A student asked, ‘Yeah, but do the wrinkles always form in the same way?’ And I thought: I haven’t the foggiest clue!” said German, a faculty member at the Thomas J. Watson College of Engineering and Applied Science’s Department of Biomedical Engineering. “So it led to this research to find out.”
It's like reading "A Discipline of Programming", by Dijkstra. That morality play approach was needed back then, because nobody knew how to think about this stuff.
Most explanations of ownership in Rust are far too wordy. See [1]. The core concepts are mostly there, but hidden under all the examples.
- Each data object in Rust has exactly one owner.
- Ownership can be transferred in ways that preserve the one-owner rule.
- If you need multiple ownership, the real owner has to be a reference-counted cell.
Those cells can be cloned (duplicated.)
- If the owner goes away, so do the things it owns.
- You can borrow access to a data object using a reference.
- There's a big distinction between owning and referencing.
- References can be passed around and stored, but cannot outlive the object.
(That would be a "dangling pointer" error).
- This is strictly enforced at compile time by the borrow checker.
[1] https://doc.rust-lang.org/book/ch04-01-what-is-ownership.htm...
I am the author of this piece, and i didn't share it to HN, I don't hang out here. I just gotta say wow, tough crowd. i wrote this piece from an emotionally low point after another fruitless day of applying to jobs. I didn't have a particular agenda in mind. I was voicing what i've been through and some of what I was experiencing with no expectations.
you'll notice in the comments section that the population of substackistan is much less FUCKING CYNICAL AND NEGATIVE than you guys, with many commenters saying they are in the same position. I heard from writers, designers, engineers, going through similar times.
my portfolio site is https://shawnfromportland.com, you can find my resume there. if you have leads that you think I might match with you can definitely send them my way, I will even put a false last name on an updated resume for you guys.
for those who are wondering, I legally changed my name to K long ago because my dad's last name starts with K, but I didn't like identifying with his family name everywhere i went because he was not in my life and didnt contribute to shaping me. I thought hard about what other name I could choose but nothing resonated with me. I had already been using Shawn K for years before legally changing it and it was the only thing that felt right.
Also, they still expect you to authenticate when they phone you. No, I'm not going to tell you my birthday when you phone me. No wonder so many people get scammed, when banks are training people on how to get scammed.
The dumbest and most obvious of realizations finally dawned on me after trying to build a software startup that was based on quality differentiation. We were sure that a better product would win people over and lead to viral success. It didn’t. Things grew, but so slowly that we ran out of money after a few years before reaching break even.
What I realized is that lower costs, and therefore lower quality, are a competitive advantage in a competitive market. Duh. I’m sure I knew and said that in college and for years before my own startup attempt, but this time I really felt it in my bones. It suddenly made me realize exactly why everything in the market is mediocre, and why high quality things always get worse when they get more popular. Pressure to reduce costs grows with the scale of a product. Duh. People want cheap, so if you sell something people want, someone will make it for less by cutting “costs” (quality). Duh. What companies do is pay the minimum they need in order to stay alive & profitable. I don’t mean it never happens, sometimes people get excited and spend for short bursts, young companies often try to make high quality stuff, but eventually there will be an inevitable slide toward minimal spending.
There’s probably another name for this, it’s not quite the Market for Lemons idea. I don’t think this leads to market collapse, I think it just leads to stable mediocrity everywhere, and that’s what we have.
There is an argument to be made that the market buys bug-filled, inefficient software about as well as it buys pristine software. And one of them is the cheapest software you could make.
It's similar to the "Market for Lemons" story. In short, the market sells as if all goods were high-quality but underhandedly reduces the quality to reduce marginal costs. The buyer cannot differentiate between high and low-quality goods before buying, so the demand for high and low-quality goods is artificially even. The cause is asymmetric information.
This is already true and will become increasingly more true for AI. The user cannot differentiate between sophisticated machine learning applications and a washing machine spin cycle calling itself AI. The AI label itself commands a price premium. The user overpays significantly for a washing machine[0].
It's fundamentally the same thing when a buyer overpays for crap software, thinking it's designed and written by technologists and experts. But IC1-3s write 99% of software, and the 1 QA guy in 99% of tech companies is the sole measure to improve quality beyond "meets acceptance criteria". Occasionally, a flock of interns will perform an "LGTM" incantation in hopes of improving the software, but even that is rarely done.
[0] https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...
Except we've squandered that 1000x not on bounds checking but on countless layers of abstractions and inefficiency.
(I work at Mozilla, but not on the VCS tooling, or this transition)
To give a bit of additional context here, since the link doesn't have any:
The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI.
In the short term the mercurial servers still exist, and are synced from GitHub. That allows automated systems to transfer to the git backend over time rather than all at once. Mercurial is also still being used for the "try" repository (where you push to run CI on WIP patches), although it's increasingly behind an abstraction layer; that will also migrate later.
For people familiar with the old repos, "mozilla-central" is mapped onto the more standard branch name "main", and "autoland" is a branch called "autoland".
It's also true that it's been possible to contribute to Firefox exclusively using git for a long time, although you had to install the "git cinnabar" extension. The choice between the learning hg and using git+extension was a it of an impediment for many new contributors, who most often knew git and not mercurial. Now that choice is no longer necessary. Glandium, who wrote git cinnabar, wrote extensively at the time this migration was first announced about the history of VCS at Mozilla, and gave a little more context on the reasons for the migration [1].
So in the short term the differences from the point of view of contributors are minimal: using stock git is now the default and expected workflow, but apart from that not much else has changed. There may or may not eventually be support for GitHub-based workflows (i.e. PRs) but that is explicitly not part of this change.
On the backend, once the migration is complete, Mozilla will spend less time hosting its own VCS infrastructure, which turns out to be a significant challenge at the scale, performance and availability needed for such a large project.
[1] https://glandium.org/blog/?p=4346
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
On the off-chance someone at Apple reads this, I'll repeat my perennial beg that Apple stops popping up 'Give me your (local admin) password right now' dialogs randomly throughout the day because the computer has a hankering to install updates or something.
Anyone with basic skills can whip up a convincing replica of that popup on the Web, and the "bottom 80%" (at least) of users in technical savvy would not think to try dragging it out of the browser viewport or switching tabs to see if it is fake or real.
The only protection against this kind of stuff is to NOT teach users that legitimate software pops up random "enter your password" dialogs in front of your work without any prompting. That's what these dialogs are doing.
Display a colorful flashing icon in the menu bar. Use an interstitial secure screen like Windows does. Whatever. But the modern macOS 'security' UI is wildly bad.
That symmetrical registration/cancellation is being slow-walked like this is absurd (but under this admin, certainly not surprising).
Neither? I'm surprised nobody has said it yet. I turned off AI autocomplete, and sometimes use the chat to debug or generate simple code but only when I prompt it to. Continuous autocomplete is just annoying and slows me down.
I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?".
I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser.
A vast majority of the hours I've spent building web sites & applications has been devoted to administrative-style UI/UX wherein we are ultimately giving the admin a way to mutate fields in a database somewhere such that the application behaves to the customer's expectations. In many situations, it is clearly 100x faster/easier/less bullshit to send the business a template of the configuration (Excel files) and then load+merge their results directly into the same SQL tables.
The web provides one type of UI/UX. It isn't the only way for users to interact with your product or business. Email and flat files are far more flexible than any web solution.
As someone who works professionally on embedded software devices that update over the internet, car companies are stuck not because they can't get software talent, but because they have no ability to actually build the electronics alongside the software, which is ultimately what constrains embedded software. Without the right hardware, the constraints are just insurmountable, you can not do X feature because board A doesn't have the API to your MCU, or it runs some dogshit speed communication system that means you have 500ms lag. The feature is just unworkable, and if the PMs push it anyways you get what happens for the legacy car makers, terrible underpowered infotainment systems with no central design philosophy, stuck in an awkward, bad, middle between a full software stack and all buttons for everything. Their model of integrating 3rd party vendor computers just doesn't really work for this kind of thing; Tesla, Rivian, and the Chinese EV makers all manufacture all their own electronics, which lets them achieve the outcome. But you can not just roll all your own electronics in a year.
I think that this comment is a great example of the total disconnect these conversations always have.
On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog.
Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them.
It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against.
In this case: this is a WordPress blog.
Remove the LTE chip and all functionality related to ads, support wireless CarPlay and android auto, and use physical buttons. You’ll win every award in the industry.
Either Klarna is really good at pulling strings to get media coverage, or mainstream media does not fact checking themselves. About a year ago, the company was everywhere in the media when its CEO announced that it created an AI bot that is doing the equivalent of 700 fulltime customer service folks.
I did what seemingly no other publication reporting on it did: signed up for Klarna, bought one item and used this bot.
I was... not impressed?
Klarna's "AI bot" felt like the "L1 support flow" that every other company already has in-place: without AI! Think like when you have a problem with your UberEats order and 80% of cases are resolved without a human interaction (e.g. when an item is missing for your item.)
I walked through the bot's capabilities [1] and my conclusion was that pretty much every other company did this before (automating the obvious support cases.) The real question should have been: why did Klarna not do it before? And when it did, why did it build a wonky AI bot, instead of more intuitive workflows than other companies did?
My sense is that Klarna really wants to be seen as an "AI-first tech company" when it goes public, and not a "buy now pay later loan company" because AI companies have higher valuations even with the same revenue. But at its core, Klarna is a finance or ecommerce-related company: an not much to do with AI (even if it uses AI tools to make its business more efficient - regardless of whether it could use non-AI tools to get the same thing done)
[1] https://blog.pragmaticengineer.com/klarnas-ai-chatbot/
I've seen a lot of high level engineers at Google leave over the past couple of years. There's vastly more pressure from management and much less trust. And a bunch of L7+ folks have been expected to shift to working on AI stuff to have "enough impact." The increased pressure has created a lot of turf wars among these folks, as it isn't enough to be a trusted steward but now you need your name at the top of the relevant docs (and not the names of your peers).
Prior to 2023 I pretty much only ever saw the L7s and L8s that I work with leave Google because there was an exciting new opportunity or because they were retiring. Now most of the people I see leave at this level are leaving because they are fed up with Google. It's a mess.
You essentially outline why it should be broken up.
I'm not convinced making the ad tech sector more competitive would prompt that outcome but, "It would disrupt mature products" isn't a compelling argument to allow the existence of a monopoly.
Google is a monopoly, they exert monopoly power and enjoy monopoly pricing.
I think the more likely outcome would be more dynamic products under smaller bannerheads.
Boy that was a confusing headline. I did not realise that fandom or giant bomb were proper nouns.
This list is very telling. Instead of a healthy marketplace of companies competing to sell their software and services, we end up with one monopolist who gives away mediocre products and in return taxes everything you buy (in the form of ad spending), and then annoys you with the same ads. How is this a desirable outcome?
In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms".
The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that they exist.
Give it more than a couple months though and I think we'll see it mature some more. We just got their auth patterns to use existing rails and concepts, just have to eat the rest of the camel.
As someone who has a terminal cancer diagnosis (and I'm mid-way through the range of time I was told I had left, months, FTR), I don't agree with a lot of this. And I'm essentially on my deathbed (mentally), even though I'm currently not bed-bound.
Yes, my state now is not a representative state of the one I was in a year ago before my health started failing. But I'm still the same person. I forgot that briefly after my terminal diagnosis, and starting doing things I thought were the right things (making sure things would be OK for my wife, tidying up a litany of messes that would be hard for her to deal with without just giving up and selling things for pennies or giving them away), but after a few weeks and speaking to the right people, I started living more normally again.
Yes, my priorities have changed massively - things that I thought were important 4 months ago are truly meaningless to me now - but many things that are important to me now were so before. And they will be until I cease to exist. I'm making the most of the time I have left because it's important that my experience at this point is as good as it can be, and because I want my wife to have good memories of our last months together.
I've never suffered from 'reason 2'. I've always felt I made the right decision at the time with the information I had and the person that I was at the time. So I don't have many regrets - none of significance to speak of, certainly. I know I am lucky in this respect.
Reason 3 is meaningless, IMO - both generally and certainly to me. I'm 53.
And I don't think many people really do think about this seriously until it's actually on the table for them. I certiainly know I didn't - even last year when I had an operation which hopefully would have removed the cancer and given me years of life, I hadn't really thought about the finality of death and what it means (or doesn't) to me. FTR I'm an Atheist, and I think that 2026 will have as much meaning/experience for me as 1969 (i.e. before I was born).
IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. That's essentially where we are today both in language repositories for OSS languages and private monorepos.
This is partly due to how we've distributed software over the last 40 years. In the 80s the idea of a library of functionality was something you paid for, and painstakingly included parts of into your size constrained environment (fit it on a floppy). You probably picked apart that library and pulled the bits you needed, integrating them into your builds to be as small as possible.
Today we pile libraries on top of libraries on top of libraries. Its super easy to say `import foolib`, then call `foolib.do_thing()` and just start running. Who knows or cares what all 'foolib' contains.
At each level a caller might need 5% of the functionality of any given dependency. The deeper the dependency tree gets the more waste piles on. Eventually you end up in a world where your simple binary is 500 MiB of code you never actually call, but all you did was take that one dependency to format a number.
In some cases the languages make this worse. Go and Rust, for example, encourage everything for a single package/mod to go in the same file. Adding optional functionality can get ugly when it would require creating new modules, but if you only want to use a tiny part of the module, what do you do?
The only real solution I can think of to deal with this long term is ultra-fine-grained symbols and dependencies. Every function, type, and other top-level language construct needs to declare the set of things it needs to run (other functions, symbols, types, etc). When you depend on that one symbol it can construct, on demand, the exact graph of symbols it needs and dump the rest for any given library. You end up with the minimal set of code for the functionality you need.
Its a terrible idea and I'd hate it, but how else do you address the current setup of effectively building the whole universe of code branching from your dependencies and then dragging it around like a boat anchor of dead code.